NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/207

Internet Message Format | 1996-08-06 | 5.6 KB

Path: mail2news.demon.co.uk!genesis.demon.co.uk
From: Lawrence Kirby <[e-mail]>
Newsgroups: comp.lang.c++,comp.lang.c,comp.std.c
Subject: Re: Hungarian notation
Date: Sat, 27 Jan 96 23:47:09 GMT
Organization: none
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <4eco1g$[e-mail]> <4ecqkn$[e-mail]> <4edore$[e-mail]>
Reply-To: [e-mail]
X-NNTP-Posting-Host: genesis.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
X-Mail2News-Path: genesis.demon.co.uk

In article <4edore$[e-mail]>
           [e-mail] "Gene Wirchenko" writes:

>[e-mail] (Peter Seebach) wrote:

>>However, given something where the *result* is implementation defined, I
>>would expect that no unexpected *behavior* was allowed.
>
>     A result is a behavior, no?

Yes, but not all behaviours produce a result i.e. a value. A result is
required in this case so not all behaviours are acceptable. The standard
does not define the meaning of basic terms (it would probably be twice as
thick if it tried to do so). For example an 'operator' is applied to one or
more 'operands' to generate a 'result'. The operands and result are values.

>     Gah, the arguments over wording.  Next: "How many angel can dance
>on the end of a C pointer?"

Indeed, wording is very important in standards!

>>>     Why are no side effects permitted?  Chapter and verse, please.
>
>>Because none are specified.  The semantics of the >> operator on signed
>>ints are implementation specified (or is that defined?) but no one would
>>tolerate it formatting disks, because it doesn't say it can, and the
>>wording makes it clear that no extra behavior is expected.
>
>     Doesn't none specified mean that the implementation is free to
>play hopscotch with nasal demons?

Only when no behaviour at all is specified. When any behaviour is specified
the implementation is bound by that specification.

>>>     What if the conversion results in overflow?

This is precisely what can give an implementation defined result. If the
conversion does *not* result in overflow then the standard defines the
behaviour exactly (OK, floating point rounding is implementation-defined).
In the case of overflow the semantics of the particular conversion being
performed comes into play:

floating point -> floating point   - undefined behaviour (6.2.1.4)
floating point -> any integer      - undefined behaviour (6.2.1.3)
any integer    -> floating point   - undefined behaviour (6.2.1.3 by lack
                                                          of definition)
any integer    -> unsigned integer - defined by standard (6.2.1.2) in terms
                                     of type limits. The type limits themselves
                                     are implementation defined, although
                                     constrained by the standard.
any integer    -> signed integer   - implementation defined (6.2.1.2) result
                                     i.e. the implementation must map the
                                     result to a value that the target type
                                     can represent and document how that is
                                     determined.

>>This is actually a legitimate question; if conversion is taken to be
>>an operation, then the previously pointed out limit on all arithmetic
>>ops comes into play, and we have full-fleged *undefined behavior* -
>>easily enough to format a disk with.

This presumably refers to 6.3 which says:

"If an exception occurs during the evaluation of an expression (that is,
 if the result is not mathematically defined or not in the range of
 representable values for its type), the behaviour is indefined."

In the last two conversion cases above the result is guaranteed to be
a representable value (even if that value is implementation defined) so
they don't invoke undefined behaviour. You need to make the distinction
between the normal unbounded mathematical result and the actual result
of the C conversion or operation. Unsigned integer arithmetic shows most
graphically that these are not in general the same, e.g. UINT_MAX+1 is
mathematically the value 1 greater than UINT_MAX but 0 in C.

>>>     If it is impossible to convert due to sizing, then the "must" is
>>>rather silly, isn't it?
>
>>Not really; it must do *some* conversion, and the conversion must be the
>>obvious one where that applies, and implementation-defined elsewhere.
>
>     My point is that if the value can't be represented then it's
>hardly the case that a conversion is being performed.  If you consider
>butchering a value to an implementation defined value to be
>conversion, gah.

Certainly a conversion is being performed - you start with a value of
one type and end up with a value of another type. The only thing of interest
here is, given the initial value, the conversion being performed and the
implementation definition, whether it should be possible to determine
the exact value of the result (hence giving a proper mathematical
function mapping) or whether the implementation could specify a
'random' result which could vary between identical conversions. The standard
seems to permit the latter although I don't see any implementation/
performance considerations resulting from requiring the former. The
standard should say that implementation-defined behaviour is deterministic.

--
-----------------------------------------
Lawrence Kirby | [e-mail]
Wilts, England | [e-mail]
-----------------------------------------